Danny Amor's Online Library

home *** CD-ROM | disk | FTP | other *** search

/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / faqs / faq / de-amiga-faq / part1 next >

Wrap

Text File | 1995-07-25 | 64.6 KB | 1,527 lines

Subject: German Amiga-FAQ (Haeufig gestellte Fragen) (Part 1 of 2) Newsgroups: de.comp.sys.amiga.misc,zer.z-netz.rechner.amiga.allgemein,de.answers,news.answers From: kellerer@informatik.tu-muenchen.de (Ignaz Kellerer) Date: 22 Nov 1994 17:04:54 GMT Posted-By: auto-faq 2.4 Archive-name: de-amiga-faq/part1 Last-modified: Dienstag, den 22. Oktober 1994 Posting-Frequency: biweekly Posting-Frequency: Alle zwei Wochen (biweekly) Häufig gestellte Fragen (FAQ) zum Amiga [1/2] ---------------------------------------------- Es folgt eine Liste häufig gestellter Fragen (FAQ = Frequently asked questions). Sie ist vor allem für neue Anwender gedacht, aber möglicherweise finden auch erfahrene Anwender Interessantes. Dies ist Teil 1, der zweite beginnt mit Kapitel 5. Die Liste ist in Ascii-Format, damit sie von jedem gelesen werden kann. Sie ist auch in AmigaGuide-, Dvi- und html-Format (für WWW-Server) erhältlich als Teil des Amiga-FAQ-Archivs. (Datei docs/misc/AmigaFAQg.lha auf dem Aminet) Bitte beachten Sie das Folgende: - Änderungen der letzten zwei Wochen sind markiert. ! diese Zeile bzw. dieser Abschnitt wurden geändert + diese Zeile ist neu < vor dieser Zeile wurde etwas gelöscht - Ein Index ist am Ende des zweiten Teils. Wenn auch dies nicht weiterhilft: Bitte schicken Sie mir eine E-Mail. Vielleicht kann ich eine Antwort in die FAQ aufnehmen. - Vorschläge, Beiträge, Kritik und Bierflaschen sind sehr willkommen. :-) Ignaz Kellerer Georg-Habel-Str. 11 81241 München (Germany) Tel. (+49) 089 / 885147 Internet: kellerer@informatik.tu-muenchen.de ==========================(Schnipp-Schnapp)=================================== Amiga-FAQ ********* Dieses Dokument enthält einige häufig gestellte Fragen und versucht, Antworten zu geben. Seine Absicht ist es, neuen Benutzern zu helfen und die Zahl der News-Artikel zu reduzieren, die erfahrene Benutzer nicht mehr sehen wollen. Bitte beachten Sie, daß viele Abschnitte bis jetzt noch fast völlig leer sind. Ich verstehe von den betreffenden Abschnitten nichts und habe nicht das Gefühl, als ob ich daran etwas ändern könnte. Damit sind Sie an der Reihe: Füllen Sie die Lücken und teilen Sie mir mit, was man hier noch aufnehmen kann! Disclaimer 1 Hardware 1 Was sind 68EC020, 68EC030 und 68LC040? 2 Was ist ein mathematischer Coprozessor (FPU) ? 3 Kann ich eine 3.5"-Festplatte im A1200 verwenden? 2 Das Betriebssystem 1 Kann ich eine andere als die eingebaute Kickstart benutzen? 2 Was entspricht unter AmigaDOS dem . (Aktuelles Directory)? 3 Der Queue-Handler PIPE: 1 Verwendung von PIPE: in einer AmigaShell 2 Das Pipe-Kommando 3 Das Pipe-Kommando in der AmigaShell 4 Die _mchar-Variable 5 Bekannte Probleme 3 Programmierung ! 1 Was ist die beste Dokumentation für Programmierer? ! 2 Was ist CATS? 3 Wo bekomme ich die Amiga-Include-Dateien? 4 Wie werde ich Developer? 5 Was für Compiler (und Assembler) gibt es? 6 Warum funktioniert keine Esc-Sequenz? 7 Kann ich AmigaBasic auf dem A1200 verwenden? 8 Wie lokalisiere ich mein Programm? 9 Wie erhält man einen Zeiger auf das Fenster einer Konsole? 10 Was sind Pragmas? 11 Mein Compiler/Linker vermißt Symbole. 12 Wie erfahre ich, was für Funktionen es gibt? 13 Der GNU C Compiler: Allgemeine Informationen und Installation 1 Aktuelle Version 2 Hardwareanforderungen 3 Wer hat es gemacht? 4 Wo finde ich die gcc-Quelltexte? 5 Inline-Dateien 6 Wie konvertiere ich die Amiga-Libraries für den gcc? 7 Wie installiere ich den gcc? 8 Kompilieren 9 Wichtige Informationsquellen 4 Anwendungen 1 Text-Editoren 2 Was für Textverarbeitungsprogramme gibt es? 3 Desktop Publishing 4 Was ist TeX und wo bekomme ich es? 5 Gibt es PostScript-Interpreter auf dem Amiga? 5 Grafik 1 Was heißt Chunky- und Planar-Display? 2 Was ist Doublebuffering? ! 3 Was für Monitore arbeiten am Amiga 1200 oder 4000? 6 Emulationen 1 Kann ich meinen Amiga unter Unix benutzen? 2 Ist es möglich, den Amiga als X11-Terminal zu benutzen? 3 Wie kann ich MS-Dos-Programme starten? 4 MsDos-formatierte Wechselplatten am Amiga verwenden 7 Verschiedenes 1 Gibt es eine Unix-Version von LhA? 2 Was sind Dateien, die mit ... enden? ! 3 Gibt es ein Programm wie Stacker, um die Hard-Disk zu packen? ! 4 Wo bekomme ich Fish-Disk xxx? 5 Wie füllt man die Tintenkartuschen der HPDeskjet-Drucker nach? 6 Was ist MUI und wo bekomme ich es? 8 Software-Quellen und andere Informationen? 1 Dateien und Datenbanken zur frei kopierbaren Software 2 Eine Sammlung von Testberichten 3 Empfangen von Dateien von einem FTP-Server 4 Empfangen von Dateien von einem Mail-Server 5 Empfangen von Dateien von einer Mailbox 6 Die Fish-PD-Serie 1 Die Amiga-Library-Disks 2 Die Fresh-Fish-Serie 7 Wie kann ich MS-Dos-Disketten lesen und schreiben? 8 Wie transportiere ich sehr große Dateien 9 Diskussionen über Mail 10 Andere FAQ's Das Amiga-FAQ-Archiv Beiträge zur Amiga-FAQ Danksagungen Index Disclaimer ********** Diese Datei steht unter dem Copyright (C) Ignaz Kellerer Georg-Habel-Str. 11 81241 München (Deutschland) Tel. (+49) 089 / 885147 Internet: kellerer@informatik.tu-muenchen.de Es ist erlaubt, sowohl veränderte als auch unveränderte Kopien dieser Datei herzustellen und zu verteilen, vorausgesetzt, daß dabei die Bestimmungen der "GNU General Public License" eingehalten werden und die Copyright-Notiz sowie diese Erlaubnis unverändert auf allen Kopien enthalten sind. Der Autor gibt *absolut keine* Garantie, daß die hier gegebenen Antworten korrekt sind. Einige dieser Antworten sind von anderen Benutzern beigetragen worden und ich habe teilweise nicht einmal die Möglichkeit, auch nur die einfachsten Tests durchzuführen. Vorschläge, weitere Beiträge, neue Fragen und Antworten, Kritik und Beschimpfungen (oh, wie ich mein `nil:' liebe :-) sind aber sehr willkommen. Siehe Beiträge. 1 Hardware ********** Dieses Kapitel enthält Fragen zur Amiga-Hardware. 1.1 Was sind 68EC020, 68EC030 und 68LC040? ========================================== Motorola, die Herstellerfirma der 680x0-Familie, bietet auch gestutzte Versionen ihrer Prozessoren an. Diese sind etwas preisgünstiger als die Originale, weshalb Commodore auch den 68EC020 in den A1200 und den 68EC030 in den A4000/030 einbaut. Dafür können sie aber auch etwas weniger. Der Unterschied zwischen 68020 und 68EC020 ist, daß letzterer nur 16MB Speicher adressieren kann. (Das ist der Grund, warum der A1200 nur maximal 10MB RAM haben kann.) In den meisten Fällen sollte man den Unterschied aber gar nicht bemerken. Das ist beim 68EC030 anders: Viele Benutzer werden feststellen, daß der 68030 eine MMU (Memory management unit) hat und der 68EC030 nicht. (Beim 68020 gibt es noch die Möglichkeit, eine externe MMU, den 68851 nachzurüsten.) Es gibt einige wichtige Programme, die eine MMU brauchen, z.B. Enforcer (ein Hilfsprogramm zur Fehlersuche), GigaMem (ein Programm zur Emulation von virtuellem RAM) oder alle aktuellen Unix-Versionen (siehe Unix). Wer eines dieser Programme verwenden will und keinen A4000 oder A3000 hat, braucht deshalb eine Prozessorkarte mit einem 68030 oder 68040. Der 68LC040 ist ein 68040 ohne FPU. Siehe FPU. 1.2 Was ist ein mathematischer Coprozessor (FPU) ? ================================================== Die Prozessoren 68000 bis 68030 bieten ausschließlich Integer (= Ganzzahl) Arithmetik. Floating-Point (Fließkomma) Operationen werden über eine Befehlssequenz ausgeführt. Floating-Point Units (FPUs) bzw. mathematische Koprozessoren sind für diese Aufgaben optimiert. Im wesentlichen kann man drei FPU-Typen unterscheiden: Den 68881, 68882 und die interne FPU des 68040. Aufgrund der Trennung von Arithmetikeinheit und Konvertierlogik (notwenig zur Konversion anliegender Zahlenformate in das prozessoreigene 80bit-Format) ist die 68882 FPU bis zu 1.5 mal schneller als die 68881. Die interne FPU des 68040 besitzt darüber hinaus eine dreistufige Pipeline, allerdings sind in ihr nicht alle Befehle der 68881/68882 realisiert. Die fehlenden (trigonometrischen) Befehle werden per Software emuliert (z.B. über die 68040.library). Für viele Programme (Raytracing, DTP, Mathematik, TeX) existieren spezielle Coprozessorversionen. Je nach Auslastungsgrad kann damit eine Geschwindigkeitssteigerung bis zum Faktor 50 erreicht werden. Michael Kaiser (kaiser@ira.uka.de) 1.3 Kann ich eine 3.5"-Festplatte im A1200 verwenden? ===================================================== Viele Leute würden statt der im A1200 üblichen 2.5"-Festplatten lieber eine 3.5"-Festplatte verwenden, da diese viel billiger sind. Das ist auch möglich, allerdings braucht man ein spezielles Kabel, um die Festplatte an den eingebauten IDE-Controller anzuschließen. Außerdem sollte man isolierendes Material zwischen die Festplatte und die Platine schieben. Es gibt Berichte über thermische Probleme, aber ich habe nichts davon bemerkt. Einige Händler bieten für ca. 40-50DM Kabel, Isoliermaterial und Informationen an, was sicherlich empfehlenswert ist. In den üblichen Magazinen sollte man diesbezügliche Anzeigen finden. Thomas Schuh (thomas@stepout.tynet.sub.org) 2 Das Betriebssystem ******************** Dieses Kapitel behandelt Fragen sowohl zum Betriebssystem Kickstart als auch zur Oberfläche Workbench. 2.1 Kann ich eine andere als die eingebaute Kickstart benutzen? =============================================================== Zunächst ein paar Worte zur Legalität der Benutzung einer anderen Kickstart: Es ist *nicht* erlaubt, Kopien von Kickstarts fremder Computer zu erstellen und auf einem anderen Computer zu benutzen! (Es ist sogar fraglich, ob man das auf eigenen Maschinen darf, wenn man mehr als einen Amiga hat.) Natürlich ist es möglich und für gewisse Personen (z.B. Developer, siehe Developer) auch erlaubt. Es gibt zwei verschiedene Möglichkeiten, eine Hardware- und eine Softwarelösung. Erstere ist, eine Platine in den Computer einzubauen, die sowohl die eigene als auch eine andere Kickstart aufnehmen kann, zwischen denen man dann umschalten kann. Die Softwarelösung benötigt ein Programm (einen sogenannten Softkicker) und die Kopie der anderen Kickstart. Der Softkicker alloziert RAM, lädt die Kickstart-Kopie in dieses RAM und führt einen Reset aus. Natürlich fehlt dann nach dem Reboot unter der neuen Kickstart etwas RAM: 256KB weniger für Kickstart 1.2 oder 1.3 und 512KB für die neueren Kickstarts. Es gibt verschiedene Softkicker, von denen einige eine MMU benötigen (siehe 68EC0xx). Ich empfehle SKick 3.43 (Aminet, Directory `util/boot') empfehlen, das keine MMU braucht und viele verschiedene Kickstarts unterstützt. Die Kopie des ROM zu erzeugen ist mit einem Programm wie dem Folgendem möglich: #include <stdio.h> #define kickorig 0xf80000 /* 0xfc0000 für Kick 1.2 und 1.3 */ #define kicklen 0x080000 /* 0x040000 für Kick 1.2 und 1.3 */ void main(int argc, char*argv[]) { FILE *fh; if ((fh = fopen("kickstart.file", "w")) != NULL) { result = fwrite(kickorig, kicklen, 1, fh); } fclose(fh); } 2.2 Was entspricht unter AmigaDOS dem . (Aktuelles Directory)? ============================================================== Unter AmigaDOS entspricht dem . (der das aktuelle Directory unter Unix und gewissen nicht-reentranten Interrupt-Handlern repräsentiert) der leere String, den man als "" schreibt. Beispiel: COPY S:Startup-Sequence "" Dies kopiert Ihre Startup-Sequence in das aktuelle Directory. Es gibt verschiedene Programme, die AmigaDOS so patchen, daß es . und .. wie unter Unix akzeptiert, z.B. UnixDirs. (Aminet, `os20/util/UnixDirsII.lha' oder Fish-Disk 837) Arno Eigenwillig (arno@yaps.dinoco.de) 2.3 Der Queue-Handler PIPE: =========================== In AmigaOS 2.04 wurde ein neuer Handler eingeführt, der es erlaubt, Daten zwischen verschiedenen Programmen auszutauschen. Dieser Handler heißt `L:Queue-Handler', ist aber besser als `PIPE:' bekannt. `PIPE:' implementiert eine echte, Unix-artige `Pipe', mit der man die Standardausgabe eines Programms als Standardeingabe eines anderen Programms verwenden kann. Es ist auch möglich, mehrere Programme über mehrere Pipes gleichzeitig zu verketten. Pipes brauchen weniger RAM für temporäre Dateien, und der Zugriff ist schneller. Allerdings unterscheidet sich `PIPE:' von Unix-Pipes in zwei wesentlichen Punkten: 1. Es handelt sich um ein Device; die Ein- und Ausgabe von Programmen muß also nicht unbedingt eine Datei sein, obwohl das meistens der Fall ist. Man kann auch `PIPE:' wie andere Devices verwenden, aber natürlich weder Directories lesen noch Seek-artige Zugriffe durchführen. 2. Es gibt keine Flush-Operation. Wenn nicht alle Daten gelesen wurden, die in `PIPE:' geschrieben wurden, dann bleiben sie stehen, bis sie evtl. von einem anderen Programm gelesen werden. Man muß also Pipes immer leeren, bevor man sie schließt. 3. Aus demselben Grund kann ein Programm blockiert werden, wenn es die interne Puffergröße überschreibt. Auch dies wird durch rechtzeitiges Leeren der Pipe vermieden. Der Handlername von PIPE: ist vollständig `PIPE:name/bufsize/bufnum', wobei `name' den verwendeten Pipekanal identifiziert und eindeutig sein sollte. Durch verschiedene Namen kann man also gleichzeitig mehrere Pipe-Kanäle öffnen. Die optionalen Argumente `bufsize' und `bufnum' geben die Größe und Anzahl der verwendeten Datenpuffer an. Meist schreibt man einfach `PIPE:name', die Vorgabegröße ist dann 4096 Bytes und die Anzahl unbegrenzt. Osma Ahvenlampi (Osma.Ahvenlampi@hut.fi) 2.3.1 Verwendung von PIPE: in einer AmigaShell ---------------------------------------------- Zunächst muß `PIPE:' natürlich mit `Mount' angemeldet sein. Dies kann durch das Kommando 1> Mount PIPE: in der Shell geschehen, ab AmigaOS 2.1 auch dadurch, daß man die Datei `PIPE' nach `DEVS:DosDrivers' schiebt. In einem AmigaShell-Fenster kann man dann folgende Kommandos eingeben: 1> Run List SYS: >PIPE:Listoutput 1> More <PIPE:Listoutput (1) Diese beiden Kommandos erzeugen also zunächst eine Liste der Dateien in `SYS:' und geben diese dann mit Hilfe des More-Kommandos aus. Man könnte auch folgendes probieren: 1> Run List SYS: NOHEAD >PIPE:Listoutput 1> Run Sort PIPE:Listoutput PIPE:Sortedoutput 1> More <PIPE:Sortedoutput Dies würde also die Liste vor der Ausgabe noch sortieren. Beachten Sie die Verwendung von `Run' außer für das jeweils letzte Programm, durch die alle Programme gleichzeitig ablaufen. Man kann auch die Programme gleichzeitig in verschiedenen Shells ablaufen lassen. Das Leeren der Pipe kann auch manuell geschehen, vorausgesetzt man kennt den Namen des verwendeten Kanals, indem man folgendes eingibt: 1> Type PIPE:name TO NIL: ---------- Footnotes ---------- (1) Dabei `1>' der Prompt der AmigaShell, die eine Eingabe erwartet. Die Nummer kann natürlich variieren. 2.3.2 Das Pipe-Kommando ----------------------- Im vorigen Beispiel ist die Verwendung von Pipes recht kompliziert, vor allem verglichen mit Unix-Pipes. Es gibt aber eine bessere Möglichkeit. Andy Finkel, der früher bei Commodore gearbeitet hat, hat auch ein Kommando `Pipe' geschrieben (was man nicht mit `PIPE:' verwechseln sollte!), das die Benutzung von Pipes stark vereinfacht. Unglücklicherweise wurde dieses Programm letzten Endes dann doch nicht in die offizielle Workbench aufgenommen, allerdings mit Billigung von Commodore veröffentlicht (Quellen: Fish-Disk 637, Aminet, `util/cli/finkelshelltools.lha'). Dieses Programm arbeitet auch unter OS3.1 noch problemlos. Die Verwendung des Pipe-Kommandos ist einfach. Man übergibt die auszuführenden Programme als Argumente an Pipe, getrennt durch das Zeichen |, z.B. 1> Pipe List SYS: | More oder 1> Pipe List: SYS: NOHEAD | Sort IN: OUT: | More Beachten Sie die Verwendung von `IN:' und `OUT:', die nötig sind, weil das Sort-Kommando nicht von der Standardeingabe lesen und nicht auf die Standardausgabe schreiben kann. Diese Devices werden durch das Kommandos Pipe simuliert. Durch die Environment-Variable _PCHAR kann man auch ein anderes Zeichen anstelle von | verwenden. 2.3.3 Das Pipe-Kommando in der AmigaShell ----------------------------------------- Es gibt ein sehr nützliches, allerdings undokumentiertes Feature der AmigaShell: Diese kennt das Pipe-Kommando! Ist die lokale Variable _PCHAR gesetzt, dann kann man Pipes sogar ohne Eingabe des Pipe-Kommandos benutzen. Die Shell erkennt das durch _PCHAR vorgegebene Zeichen und ruft für Kommandozeilen, die es enthalten, automatisch Pipe auf. Am besten wird das folgende Kommando in `s:Shell-Startup' eingetragen: 1> Set _pchar "|" (1) Man kann die vorigen Beispiele dann so ausführen: 1> List SYS: | More oder 1> List SYS: NOHEAD | Sort IN: OUT: | More Dies entspricht also völlig den Unix-Pipes. ---------- Footnotes ---------- (1) Die Anführungsstriche sind wesentlich! Wenn _PCHAR bereits gesetzt ist, wird sonst angenommen, es handele sich bereits um einen Aufruf von Pipe. Dies kann etwa dann geschehen, wenn aus einer Shell eine neue gestartet wird. 2.3.4 Die _mchar-Variable ------------------------- Die lokale Variable _mchar legt das Zeichen fest, das als Kommandotrenner dient. Setzt man also 1> Set _mchar ";" dann kann man in der Shell die Befehle hintereinanderfügen, durch den Strichpunkt getrennt. 2.3.5 Bekannte Probleme ----------------------- *F:* Ich bekomme die Fehlermeldung PIPE: Unknown command wenn ich das Kommando `List SYS: | More' ausführe, obwohl `PIPE:' mit `Mount' angemeldet ist. Was ist falsch? *A:* Die Shell sucht nach dem Kommando `Pipe' in der Fehlermeldung, nicht nach dem `PIPE:'-Device. Dieses Kommando ist also nicht im Suchpfad (meist in `C:') installiert. *F:* Ein Requester meldet Please insert volume PIPE: in any drive wenn ich eines der Kommandos aus den Beispielen ausführen will. *A:* `PIPE:' ist nicht angemeldet. Dies kann mit `Mount PIPE:' geschehen. *F:* Wenn ich eines der Beispiele ausführe, dann eröffnet das `More'-Kommando ein Fenster, aber dort erscheint nichts/ eine Fehlermeldung erscheint/ein Filerequester erscheint. *A:* Sie verwenden ein anderes More-Kommando als das aus der Workbench. Verwenden Sie einen anderen Namen oder installieren Sie ein More, das Pipes unterstützt, z.B. das More von Commodore, Less oder Most. 3 Programmierung **************** In diesem Kapitel finden vermutlich nur Programmierer Interessantes. ! 3.1 Was ist die beste Dokumentation für Programmierer? ! ====================================================== Die beste verfügbare Dokumentation sind sicherlich die RKM's (ROM Kernel Manuals, die schwarzen) von Commodore. Sie werden von Addison-Wesley veröffentlicht. The Amiga ROM Kernel Manual: Libraries, ISBN 0-201-56774-1 The Amiga ROM Kernel Manual: Devices, ISBN 0-201-56775-X The Amiga ROM Kernel Manual: Includes and Autodocs, ISBN 0-201-56773-3 The Amiga Hardware Manual, ISBN 0-201-56776-8 The Amiga User Interface Style Guide, ISBN 0-201-57757-7 Vor allem die Libraries sind ein Muß. Weniger nützlich sind die Includes und Autodocs: Sie sind auf Diskette als Online-Hilfe sicher nützlicher. Siehe Include-Dateien. AmigaDOS wird in diesen Büchern kaum behandelt. Die Autodocs geben einige Informationen, aber um tiefer einzusteigen braucht man das The AmigaDOS Manual, 3rd Edition, ISBN 0-553-35403-5 ebenfalls von Commodore, das von Bantam Books herausgegeben wird. Eine gute Wahl ist auch The Amiga Guru Book von Ralph Babel. Das Buch beginnt mit einem ca. 250-seitigen allgemeinen Überblick über verschiedenste Aspekte der Programmierung des Amiga. Für Anfänger dürften vor allem die Abschnitte über die Amiga-Datentypen sowie die Amiga-Includes und die amiga.lib interessant sein, aber auch Erfahrene finden hier mit Sicherheit noch Neues, was zum Teil nicht einmal in den RKM's enthalten ist. Den größten Teil des Buches nehmen aber 500 Seiten nur zu AmigaDOS ein. Dieser Teil ist meines Erachtens der wichtigste, weil das AmigaDOS-Manual der schlechteste Teil der offiziellen Dokumentation ist. Das Buch ist sehr dicht geschrieben und deshalb weniger leicht lesbar als die RKM's, aber ich empfehle es als Zusatz und vor allem anstelle des AmigaDOS-Manuals. (Allerdings ist das Guru-Buch kein Ersatz für die Libraries & Devices, die hier nicht behandelt werden.) Unglücklicherweise hat das Buch keine ISBN-Nummer und ist deshalb nur bei den folgenden Adressen erhältlich: ! Almathera Systems Limited ! Southerton House ! NBG USA, Inc. Boundary Business Court ! 482 Holly Avenue 92-94 Church Road ! St. Paul, MN 55102 Mitcham, Surrey CR4 3TD ! USA England ! Voice: +1 (612) 290 9447 Voice: +44 181 687 0040 ! Fax: +1 (612) 290 9449 Fax: +44 181 687 0490 ! E-Mail: <almathera@cix.compulink.co.uk> ! ! Stefan Ossowskis Schatztruhe ! Hirsch & Wolf OHG Gesellschaft für Software mbH ! Mittelstraße 33 Veronikastraße 33 ! D-56564 Neuwied D-45131 Essen ! Germany Germany ! Voice: +49 (2631) 8399-0 Voice: +49 (201) 788778 ! Fax: +49 (2631) 8399-31 Fax: +49 (201) 798447 ! E-Mail: <stefano@tchest.e.eunet.de> ! ! Someware ! 27 rue Gabriel Péri ! 59186 Anor ! France ! Voice: +33 27596000 ! Fax: +33 27595206 ! E-Mail: <didierj@swad.someware.com> Für weitere Informationen empfehle ich auch die FAQ von Marc Atkins über Bücher zum Thema Amiga, die alle 4 Wochen in `comp.sys.amiga.misc' erscheint. ! 3.2 Was ist CATS? ! ================= Dies ist eine Abteilung von Commodore West Chester, die früher `Commodore Amiga Technical Support' hieß und später in `Commodore Application and Technical Support' umbenannt wurde. Die Mitglieder arbeiten unabhängig von der Entwicklungsabteilung, aber eng mit ihr zusammen, und versuchen, Entwicklern außerhalb von Commodore beim Erstellen guter Amiga-Anwendungen zu helfen, sei das eine Hard- oder Software. Dazu hat CATS eine Menge an Informationen und Tools gesammelt, auf Floppy, CD oder Papier. Ein großer Teil dieses Materials ist auch der Allgemeinheit, d. h. für Nicht-Developer zugänglich. Aber bitte CATS nicht mit einer Hotline verwechseln! Amerikaner können das Material von ! CATS ! Commodore Electronics Limited ! 950 Rittenhouse Road ! Norristown, PA 19403 bekommen, der Distributor für ganz Europa ist die Fa. Hirsch & Wolf Mittelstr. 33 56564 Neuwied Tel. 02631/83990 Dr. Peter Kittel, peterk@cbmger.de.so.commodore.com 3.3 Wo bekomme ich die Amiga-Include-Dateien? ============================================= Der einzige legale Weg, die Include-Dateien und die AutoDocs zu bekommen (und Sie sollten sie bekommen, sie sind *sehr* nützlich!), ist, Developer zu werden (siehe siehe Developer) oder das sogenannte `NDU' (Native developers update kit, auch als `NDUK', `NDK' bekannt oder `ADU' für Amiga Developer Update) bei CATS zu kaufen. Siehe CATS. Es kostet etwa 50DM, was sicher ein fairer Preis ist. Dabei handelt es sich um ein 5-Disketten-Set, das neben den aktuellen Includes und AutoDocs auch Tools für Programmierer, z.B. Enforcer, Mungwall, Sushi und die debug.libg (zum Debuggen) sowie anderes, z.B. CatComp (siehe Lokalisierung) oder Report (für Bug-Reports oder Vorschläge an Commodore) enthält. Die aktuelle Version ist 3.1 und für Programmierer beinahe obligatorisch. Wem die Includes genügen, der kann diese über ein Update seines Compilers (nur kommerzielle Compiler) oder von den Fish-CDs bekommen. Siehe Fish-CD. 3.4 Wie werde ich Developer? ============================ Um Developer zu werden, braucht man die `ADSP'-Antragsformulare (Amiga developer support program). Um diese zu bekommen, sollte man einen Brief an die lokale Commodore-Niederlassung schreiben und nach diesen Papieren fragen, in denen das weitere erklärt wird. In Deutschland ist die Adresse folgende: Commodore Lyoner Straße 38 60528 Frankfurt Es gibt drei verschiedene Arten von Developern: *Registered* Hier bekommt man vor allem Zugang zum CBMNET (eine Art Commodore-internes Usenet), über das man direkt mit anderen Entwicklern auch von Commodore selber über seine Probleme diskutieren kann. Die Jahresgebühr beträgt 150 DM, die einmalige Aufnahmegebühr 50 DM. *Certified* Dies ist die interessanteste Klasse: Man bekommt von der meisten Systemsoftware die aktuellen Beta-Versionen (z. B. Kickstart und Workbench) sowie die dazugehörigen Includes und AutoDocs. Certifieds bekommen aber nicht jede Beta und in der Regel auch keine Hardware-Beta. Man bezahlt 400 DM pro Jahr dafür und eine einmalige Aufnahmegebühr von 100 DM. *Commercial* Kommerzielle Entwickler bekommen im wesentlichen dieselben Informationen wie die "Zertifizierten", allerdings kompletter, sprich auch Beta-Hardware, und etwas früher. Dies hat auch seinen Preis: 700DM pro Jahr plus einmalige Aufnahmegebühr von 100DM. Die Preise und die angebotenen Möglichkeiten können von Land zu Land verschieden sein, auch gibt es meines Wissens nicht in allen Ländern den "Registered". Ein guter Tip ist es, eine Gruppe zu bilden und damit die Kosten zu reduzieren. Alle Entwickler müssen Non-disclosure agreements (`NDA') unterzeichnen. Diese besagen, daß sie über die erhaltenen Informationen außerhalb von speziell dazu freigegebenen Orten oder Kanälen nicht einmal zu anderen Entwicklern sprechen dürfen, so lange sie nicht die explizite Erlaubnis dazu von Commodore haben. 3.5 Was für Compiler (und Assembler) gibt es? ============================================= Es gibt viele Programmiersprachen auf dem Amiga, kommerzielle Compiler ebenso wie frei kopierbare. Ich möchte nur diejenigen aufzählen, die mir bekannt sind oder die ich aus einem anderem Grund für erwähnenswert halte. *Assembler* Alle C-Compiler beinhalten einen Assembler. Frei kopierbar und zuverlässig sind A68K und PhxAss. (Aminet, Directory `dev/asm' oder Fish-Disks 521 bzw. 906) *C* *C++* Frei kopierbare C-Compiler sind der `gcc' (der sein eigenes Directory `dev/gcc' auf dem Aminet hat) und die Probeversion (mit der man aber schon eine ganze Menge anfangen kann) von `Dice' (per FTP von `ftp.uni-paderborn.de', Directory `/news/comp.binaries.amiga/volume91/languages' oder auf Fish disk 491). Der große Vorteil von gcc ist, daß man ihn auf der ganzen Welt und auf nahezu jedem Computer findet. Ein weiterer Vorteil ist, daß er sogar einen C++-Compiler enthält! Aber er ist langsam und benötigt 4MB RAM oder mehr. Siehe Der GNU C Compiler. Siehe Mail-Listen. Kommerzielle C-Compiler sind `Aztec-C', `Dice' und `SAS-C'. `Aztec-C' wird jedoch leider nicht mehr weiterentwickelt. Was die kommerziellen Compiler auszeichnet, sind ihre hervorragenden Source-Level-Debugger, die den anderen fehlen. SAS hat leider angekündigt, den Amiga-Compiler nicht weiter zu unterstützen. Verkauft wird er aber noch, und da er gegenwärtig noch voll aktuell ist und sogar einen Crosscompiler von C++ in C enthält (der vom Debugger unterstützt wird), ist er meines Erachtens derzeit das beste Angebot, insbesondere zu dem äußerst günstigen Preis von 184.-DM für Studenten und Besitzer anderer Compiler. In Deutschland erhält man SAS/C bei SAS Institute GmbH Postfach 10 53 40 69043 Heidelberg Deutschland Telefon: 06221/4160 EMail: eurdoc2@vm.sas.com Dice bietet wie SAS einen Sonderpreis für Schüler und Studenten von ca. 130.-DM. Der Compiler ist stabil und vor allem sehr schnell. Der größte Nachteil von Dice ist (verglichen mit den anderen kommerziellen Compilern) der Debugger, ein sogenannter Source-Line-Debugger: Dies bedeutet, daß man den Quelltext sieht und das Programm Schritt für Schritt abarbeiten kann, aber leider nur Speicher und nicht etwa bestimmte Variablen anzeigen kann. Informationen über Dice: info@oic.COM. Comeau C++ ist ebenfalls ein Crosscompiler, was an und für sich kein Problem wäre. Aber Comeau C++ hat keinen integrierten C-Compiler, man braucht also zusätzlich SAS-C, Aztec-C oder Dice. Dafür ist er kompatibel zu AT&T cfront 3.0, unterstützt Exceptions und läuft wie `gcc' auf vielen verschiedenen Systemen. In Deutschland wird auch Maxxon C++ angeboten, über das ich nichts sagen kann. Beide Compiler sind kommerziell. Comeau's Adresse ist: Comeau computing 91-34, 120th Street Richmond Hill, NY, 11418-3214 USA EMail: Greg Comeau, comeau@bix.com *Forth* JForth soll eine exzellente Forth-Version sein. Unter anderem enthält es objektorientierte Erweiterungen, ein volles Amiga-Interface und einen Anwendungsgenerator. Es ist erhältlich von: Delta Research P.O. Box 151051 San Rafael, CA 94915-1051 Phone: (415) 453-4320 EMail: Phil Burk, phil@ntg.com Mike Haas, haas@starnine.com *Fortran* (Seufz! Es gibt immer noch Leute, die es brauchen :-<) Frei kopierbar sind BCF (Fish disk 470) und f2c, der Fortran in C-Quelltext umwandelt. (Aminet, Directory `/dev/lang'). Ein kommerzieller Compiler ist von ABSoft erhältlich. Allerdings sind dies alles nur Fortran-77-Compiler, es gibt keine Fortran-90-Compiler auf dem Amiga. *Lisp* Frei kopierbare Lisp-Interpreter sind XLisp (Fish-Disk 181) und OakLisp (Fish-Disks 519 und 520) und CLISP (`/pub/lisp/clisp/binaries/amiga' at `ma2s2.mathematik.uni-karlsruhe.de'). Auch Compiler gibt es: Gambit (Fish-Disks 764 und 765) sowie Scheme-to-C (Fish-Disks 556-558). Von Interesse ist vielleicht eine Mail-Liste: Senden Sie dazu eine Mail mit dem Wort `Subscribe' an `amigalisp@contessa.phone.net'. *Prolog* `/dev/lang/UNSWProlog.lha' und `dev/lang/sbp3_1e' auf dem Aminet sowie `SBProlog' auf der Fish-Disk 141 und `SBProlog' auf der Fish-Disk 145 sind frei kopierbare Prolog-Interpreter. *Modula-2* M2Amiga wird in Europa und Benchmark Modula-2 in den USA angeboten. Beide sollen sehr gut sein und sowohl über gute Source-Level-Debugger als auch eine umfangreiche Bibliothek verfügen. Besonders M2Amiga wird sehr gut unterstützt durch eine deutsche Benutzergruppe (AMOK), die z.B. eine eigene PD-Serie anbieten. Siehe Mail-Listen. M2Amiga bekommt man bei A+L AG Daderiz 61 2540 Grenchen Schweiz Tel.: +41/65/52 03-11 Fax: -79 und Benchmark Modula-2 ist erhältlich von: Armadillo Computing 5225 Marymount Drive Austin, Texas 78723 USA Phone/FAX: 512/926-0360. EMail: Jim Olinger, jolinger@bix.com *Oberon* *Oberon-2* Es gibt zwei Oberon-2-Compiler für den Amiga: AmigaOberon ist wie M2Amiga von A+L und kommerziell. Der Compiler kommt mit einer integrierten Entwicklungsumgebung (incl. freikonfigurierbarem Editor) und umfangreicher Modulbibliothek. Library Linker zum einfachen Erzeugen von AmigaOS Shared Libraries sowie Run-time Source-Level-Debugger sind ebenfalls erhältlich. Oberon-A ist ein Freeware-Compiler, allerdings erst in einer Beta-Version, insbesondere sind die Modulbibliotheken unvollständig. (Quelle: Aminet, Directory `dev/obero'). Siehe Mail-Listen. Für beide Compiler gibt es Unmengen von Modulen und Bsp.-Sourcen auf AMOK-Disks. *Pascal* Es gibt einen PD-Compiler namens PCQ (Aminet, Directory `dev/lang' oder Fish-Disk 511), der allerdings kein voller Pascal-Compiler ist und dem sehr wesentliche Dinge fehlen. P2C konvertiert Pascal in C und ist auf der Fish-Disk 341 zu finden. (Aminet: `/dev/misc/p2c120.lha') Ferner gibt es zwei kommerzielle Compiler namens HiSoft-Pascal (von der gleichnamigen Firma) und KickPascal von Maxxon. HiSoft und P2c behaupten, kompatibel zu Turbo-Pascal 5.0 zu sein. HiSoft hat außerdem einen guten Source-Level-Debugger. 3.6 Warum funktioniert keine Esc-Sequenz? ========================================= Viele Drucker kommen mit einem Handbuch, das erklärt, welche Esc-Sequenzen welche Funktion auslösen. Aber wenn man diese Sequenzen dann einmal ausprobiert, passieren oft merkwürdige Sachen, nämlich entweder gar nichts oder etwas ganz anderes, als geplant war. Und das hat auch einen Grund, nämlich die Amiga-Druckertreiber. Diese Treiber sind so gebaut, daß sie nur einen bestimmten Satz `ANSI-Esc-Sequenzen' verstehen, nicht die (verschiedenen) druckereigenen, von den verschiedenen Druckerherstellern definierten. Der Sinn dabei ist, daß jede Anwendung auf dem Amiga nur diesen einen Standardsatz an Sequenzen verwendet und so nicht zu wissen braucht, welcher Drucker tatsächlich angeschloßen ist. Der Druckertreiber übersetzt dann diese Standardsequenzen in die druckereigenen. Eine Liste der verfügbaren ANSI-Esc-Sequenzen findet sich im aktuellen Workbench-Handbuch (oder in älteren AmigaDOS-Handbüchern). Wenn Du nun eine Steuersequenz an den Drucker schicken willst, die es nicht als ANSI-Sequenz gibt, so hast Du zwei Möglichkeiten, dies doch zu erreichen: 1. Umgeh den Druckertreiber (der erfolglos versuchen würde, die Sequenz zu interpretieren oder zu übersetzen) und sende die Ausgabe *nur* für die Länge dieser Sequenz an `PAR:' (bzw. `SER:'). Dabei muß man die Druckerausgabekanäle umständlich oft umschalten, und man muß wissen, wo der Drucker angeschlossen ist (`PAR:' oder `SER:'). 2. Benutze eine spezielle ANSI-Sequenz, genau für diesen Fall gedacht: `Esc[<n>"<x>' wobei `<n>' die dezimal geschriebene Anzahl an Bytes in der Sequenz `<x>' ist, die gerade die spezielle Drucker-Sequenz enthält. Diese ANSI-Sequenz sagt dem Druckertreiber, daß er die nächsten `<n>' Bytes nicht interpretieren oder übersetzen soll. Aber beide Methoden haben einen grossen Nachteil, wenn sie in einem Anwendungsprogramm verwendet werden: Man verliert die Druckerunabhängigkeit! Solange man sich an die ANSI-Sequenzen hält, kann man jeden Drucker der Welt ansteuern, solange es einen Amiga-Druckertreiber für ihn gibt. Wenn man anfängt, druckereigene Sequenzen zu verwenden, ist das Programm an diesen einen Druckertyp gebunden und mit keinem anderen benutzbar (oder man müßte einige dutzend neue Druckertreiber für dieses Programm erstellen). Dr. Peter Kittel, peterk@cbmger.de.so.commodore.com 3.7 Kann ich AmigaBasic auf dem A1200 verwenden? ================================================ Letztens ging eine Kontroverse über AmigaBasic durch die Netze: Ich sagte, auf dem A1200 läuft es einigermaßen problemlos, jemand anders berichtete, daß es bei jedem kleinsten Fehler sofort komplett abstürzt, was ich nicht nachvollziehen konnte. Jetzt kann ich es: Es liegt am Sound-Prefs-Editor. Wenn man in ihm die Sound-Ausgabe ganz abschaltet, kann man mit AmigaBasic arbeiten. Wenn hier ein Sound (z. B. Piepsen) angewählt ist, kollidiert das mit dem Sound, den AmigaBasic offensichtlich zu Fuß und nicht ganz korrekt selber erzeugen will, bumm. Abhilfe also: 1. Im Sound-Editor den Ton abstellen. 2. Auf einem A4000 (oder einem A1200 mit Fast-RAM-Erweiterung (1)) muß man zusätzlich NoFastMem aktivieren. 3. Möglichst SUBs vermeiden und stattdessen herkömmliche GOSUBs benutzen, dann ist die Kompatibilität zu neueren Prozessoren höher. Dr. Peter Kittel, peterk@cbmger.de.so.commodore.co ---------- Footnotes ---------- (1) Nur bei einem zusätzlichen Prozessor 3.8 Wie lokalisiere ich mein Programm? ====================================== Nehmen wir an, wir wollen ein `HelloLocalWorld.c' schreiben. Das letztendliche Programm sieht dann ungefähr so aus: #include "HelloLocalWorld_Cat.h" #include <clib/exec_protos.h> struct Library *LocaleBase; void main(int argc, char *argv[]) { /* Öffne die locale.library. (Kein Abbruch, wenn sie nicht da ist, weil dann einfach die eingebauten Strings verwendet werden. Aus diesem Grund auch keine Verwendung des AutoOpening, auch wenn es der Compiler beherrscht.) */ LocaleBase = OpenLibrary("locale.library", 38); OpenHelloLocalWorldCatalogs(NULL, NULL); printf(GetString(MSG_Hello)); CloseHelloLocalWorldCatalog(); if (LocaleBase) CloseLibrary(LocaleBase); } Die Funktion GetString prüft, ob die gewünschten Kataloge vorhanden sind und liefert einen Zeiger auf einen String, entweder den eingebauten oder den Katalogstring. (In unserem Fall den deutschen String.) Der Hauptunterschied zum gewohnten HelloWorld.c ist also (abgesehen von der minimalen Initialisierung und dem Gegenstück am Programmende), Strings durch einen Funktionsaufruf zu ersetzen. Man braucht also eine Datei `HelloLocalWorld_Cat.c', die die Funktionen OpenHelloLocalWorld, GetString, CloseHelloLocalWorld_Cat.h und die eingebauten Strings enthält (dies könnte ein Array sein, das unter anderem array[MSG_Hello] = "Hello, local world.\n"; enthält) und ein Includefile `HelloLocalWorld_Cat.h', das die ID's wie MSG_Hello definiert. Es ist nicht nötig zu wissen, wie diese Dateien intern arbeiten, insbesondere benötigt man auch keine Kenntnis der `locale.library'! Dazu gibt es verschiedene Kataloggeneratoren (im Folgenden KG), nämlich `CatComp' (nur für Developer), `KitCat' (nur deutsche Dokumentation, was hierzulande kein Problem ist), `MakeCat' (das ich nicht kenne) und `FlexCat' (das ich empfehle, einerseits, weil es sehr flexibel im erzeugten Source ist und z.B. Lokalisierung unter 2.0 sowie beliebige Programmiersprachen unterstützt, selbst Amiga-E, Cluster, Pascal, ... und andererseits, weil es von mir ist ;-) ), die diese Dateien sowie die Kataloge erzeugen. (Der obige Quelltext könnte je nach KG leicht unterschiedlich aussehen.) Siehe Aminet, directory `dev/misc'. Wie funktionieren diese KGs? Zunächst erzeugt man eine sogenannte `Katalogbeschreibung' (`Catalog description'), die so aussehen könnte: ; Mit einem Semikolon beginnende Zeilen sind Kommentare # language english ; die Sprache der eingebauten Strings # version 0 ; die Katalogversion (0 = beliebig) MSG_Hello (1/15/30) Hello, local world Jeder String wird durch zwei Zeilen wie die letzten beiden definiert: MSG_Hello ist die String-ID, (1/15/30) gibt den Wert der ID sowie die minimale und maximale Länge an. (Diese Argumente können auch weggelassen werden, in welchem Fall einfach die nächste freie ID verwendet wird.) Nun schreiben wir das Programm. Sobald es fertig ist, wird mit dem KG eine sogenannte Katalogübersetzung (eine für jede andere Sprache als die eingebaute) erzeugt, die so aussehen könnte: ; Mit einem Semikolon beginnende Zeilen sind Kommentare ## language deutsch ; the catalog language ## version $VER: Deutsch.catalog 1.0 (22.12.93) ; the catalog files version string MSG_Hello ; Hello, local world Beachten Sie die leere Zeile nach der String-ID! (Die Argumente von ## language und ## version wären vielleicht leer.) Hier müssten jetzt die deutschen Strings eingesetzt werden. Mit dem KG wird daraus dann der eigentliche `Katalog' erzeugt. (Beachten Sie auch, daß hier die Angaben über String-ID und Stringlänge fehlen: Sie werden aus der Katalogbeschreibung übernommen. Wenn das Programm verändert wird (neue Strings, andere Längen) und die Katalogbeschreibung sich damit ebenfalls ändert, dann kann der KG analog benutzt werden, um auch die Katalogübersetzung und damit den Katalog auf den neuesten Stand zu bringen. 3.9 Wie erhält man einen Zeiger auf das Fenster einer Konsole? ============================================================== Die folgende Funktion liefert den Window-Zeiger eines CON-Fensters. Sie kann unter allen Versionen des Amiga-OS ausgeführt werden. struct Window *getConWindowPtr(BPTR fh) { struct Window *w; struct FileHandle *cfh; struct StandardPacket *sp; struct InfoData *id; struct MsgPort *mp; w = NULL; if ((cfh = BADDR(fh))->fh_Type != NULL) { if (sp = AllocMem(sizeof (struct StandardPacket), MEMF_PUBLIC | MEMF_CLEAR)) { if (id = AllocMem(sizeof (struct InfoData), MEMF_PUBLIC | MEMF_CLEAR)) { if (mp = CreatePort(NULL, 0)) { sp->sp_Msg.mn_Node.ln_Name = (char *) &sp->sp_Pkt; sp->sp_Pkt.dp_Link = &sp->sp_Msg; sp->sp_Pkt.dp_Port = mp; sp->sp_Pkt.dp_Type = ACTION_DISK_INFO; sp->sp_Pkt.dp_Arg1 = MKBADDR(id); PutMsg(cfh->fh_Type, &sp->sp_Msg); (void) WaitPort(mp); (void) GetMsg(mp); if (sp->sp_Pkt.dp_Res1) w = (struct Window *) id->id_VolumeNode; DeletePort(mp); } FreeMem(id, sizeof (struct InfoData)); } FreeMem(sp, sizeof (struct StandardPacket)); } } return w; } Anmerkungen: * Auf ein CON-Fenster direkt zuzugreifen kann Konflikte mit Aktionen des CON-Handlers hervorrufen. Seien Sie vorsichtig! * Um den Window-Zeiger einer CLI-Konsole zu erhalten, übergibt man ein durch Open("*", MODE_OLDFILE) gewonnenes FileHandle an obige Funktion. * Das Ergebnis der obigen Funktion kann sehr wohl NULL sein, etwa im Falle eines AUX-Handlers oder falls ein AUTO-CON-Handler sein Fenster nicht öffnen kann. * Schickt man ein ACTION_DISK_INFO-Paket an einen AUTO-CON-Handler (2.0+), so verliert dessen Fenster seine speziellen AUTO-Eigenschaften (es kann also nicht mehr durch das Betätigen des Close-Gadgets geschlossen werden), weil der in id_VolumeNode gelieferte Window-Zeiger gültig bleiben muß. * Alles in allem: Verwenden Sie diese Funktion nicht. :-) Weitere Informationen finden Sie auf den Seiten 273, 276, 435, 463, 485 und 629 im "Amiga Guru Book" (siehe Dokumentation). Ralph Babel, rbabel@babylon.pfm-mainz.de 3.10 Was sind Pragmas? ====================== Pragmas sind spezielle Anweisungen an den C-Compiler. Zwei Probleme entstehen bei der Verwendung von Pragmas: 1. Pragmas sind hochgradig compilerspezifisch. Nicht einmal die Amiga-Compiler haben dieselben Pragmas, selbst wenn damit das gleiche bewirkt wird. 2. Man kann sich nicht darauf verlassen, daß ein Compiler Pragmas ignoriert, die er nicht versteht. Dies gilt selbst dann, wenn man einen Ausdruck wie den folgenden verwendet: #ifndef MY_COMPILER #pragma DoAnything #endif Das letztere Problem läßt sich umgehen, indem man Pragmas wie folgt in eigene Include-Files setzt. (Das gleiche gilt übrigens auch für Präprozessor-Kommandos wie #asm (Aztec-C) oder #extern (C++).) #ifndef MY_COMPUTER #include <mypragmas.h> #endif Aber was machen Pragmas auf dem Amiga? Meistens werden sie verwendet, um dem Compiler mitzuteilen, wie gewisse Library-Funktionen aufgerufen werden. (Tatsächlich wird fast immer diese Verwendung gemeint, wenn Amiga-Besitzer über Pragmas sprechen.) Gewöhnliche C-Funktionen erwarten ihre Argumente auf dem Stack, Library-Funktionen dagegen in bestimmten Registern. Ferner erwarten sie den `Library-Base-Pointer' in Register a6. Betrachten wir eine Pragma-Anweisung von Aztec-C: #pragma amicall(SysBase,0xd2,FreeMem(a1,d0)) Dies weist den Compiler an, das erste Argument in Register a1 und das zweite in d0 zu laden. Ferner wird der Inhalt der Variablen SysBase in Register a6 geladen. Maxon-Pragmas sehen genauso aus, Dice- und SAS-Pragmas sind allerdings etwas komplizierter: #pragma libcall SysBase FreeMem d2 0902 Hier ist d2 (wie 0xd2 oben) der `Library-Vektor-Offset' (siehe nächstes Beispiel). Die letzte Ziffer ist die Zahl der Argumente, die davorstehende 0 ein Code für das Register mit dem Ergebnis und die davor stehenden Ziffern sind Codes für die Register mit den Argumenten in verkehrter Reihenfolge. (Die Codes bedeuten 0=d0, 1=d1, .., 8=a0, 9=a1, a=a2, ..) Ein Kommando wie `FreeMem(fib,sizeof(*fib);' würde ein Compiler nun in folgenden Code übersetzen: move.l _fib,a1 move.l 260,d1 ; sizeof(struct FileInfoBlock) move.l _SysBase,a6 jsr -0xd2(a6) ; 0xd2 = _LVOFreeMem FreeMem in dieser Art aufzurufen ist kürzer und schneller als zunächst die Argumente auf den Stack zu legen und dann eine Funktion _FreeMem aufzurufen, die letzten Endes doch nur dasselbe tun und die Argumente vom Stack in dieselben Register laden würde. Das Portierungsproblem der Pragmas umgeht man, indem man sie folgendermaßen in den eigenen Quelltext einbindet: /* Lade den Funktionsprototyp. Dieser ist nicht vom */ /* verwendeten Compiler abhängig. */ #include <clib/exec_protos.h> /* Pragmas sind vom Compiler abhängig, aber wenigstens */ /* die Namen der Dateien mit Pragmas sind relativ */ /* einheitlich. */ #ifdef AZTEC_C #include <pragmas/exec_lib.h> #endif #if defined(__SASC) || defined(_DCC) || defined(__MAXON__) #include <pragmas/exec_pragmas.h> #endif #ifdef __GNUC__ #include <inline/exec_lib.h> #endif Das obige Beispiel kann problemlos mit allen angegebenen Compilern verwendet werden und produziert optimalen Code. Eine abschließende Frage bleibt allerdings: Wie bekommt man die Pragmas? Die meisten Compiler haben bereits fertige Pragmas im Lieferumfang. Allerdings hilft das nicht, wenn man z.B. eine neue Library benutzen möchte oder nur die Pragmas einer veralteten Version hat. In diesem Fall kann man die Pragmas selbst aus den sogenannten `FD'-Files erzeugen. Dazu haben die meisten Compiler ein Utility namens `fd2pragma'. (Das NDU hat z.B. ein Directory namens FD, in dem die FD-Files aller Libraries und Devices des OS enthalten sind. siehe Include-Dateien) Es gibt auch ein frei kopierbares fd2pragma, das Pragmas für Aztec, Dice, SAS und Maxon sowie LVO-Files für den Aztec-Assembler und eventuelle Tag-Versionen produziert. (Aminet, `dev/misc/fd2pragma2_0.lha' oder auf den Fish-CDs) Für Pragmas unter dem gcc siehe Inline-Dateien. 3.11 Mein Compiler/Linker vermißt Symbole. ========================================== Zunächst sollte man sich versichern, daß die Funktion tatsächlich fehlt: Z.B. Floating-Point-Funktionen befinden sich in einer speziellen Link-Library, die erst mit der Option `-lm' eingebunden wird. Ferner kann es eine fehlende Variable sein: Wenn man z.B. ohne es zu bemerken eine Intuition-Funktion benutzt, dann wird der Linker über das Fehlen eines Symbols `IntuitionBase' klagen. In diesem Fall muß man also lediglich das Folgende irgendwo im globalen Teil seines Quelltextes einbauen: struct Library *IntuitionBase; (Und vergessen Sie nicht, die Library mit OpenLibrary() zu eröffnen und mit CloseLibrary() zu schließen!) :-) Allerdings könnte die Funktion natürlich tatsächlich fehlen. Wenn man zum Beispiel nur die Version 2.0 der amiga.lib hat, dann fehlen etwa die Locale-Funktionen oder die Memory-Pool-Funktionen, obwohl sie prinzipiell verwendbar sind. (1) Die einfachste (und beste) Lösung ist, das sogenannte NDU zu kaufen. Siehe Include-Dateien. Wer nicht solange warten möchte, für den ist die Frage, welche Art von Funktion in seiner Link-Library fehlt: * Einfache Amiga-Library-Funktionen (z.B. `exec/AllocPooled' oder `locale/OpenCatalogA') kann man mit Pragmas aufrufen und braucht dann lediglich Informationen über die Aufrufkonventionen (Library-Base, Library-Vektor-Offset und Argumentregister) * Tag-Funktionen sind meistens einfach Zwischenfunktionen, die ihre Argumente auf dem Stack erwarten und dann die eigentliche Library-Funktion aufrufen. Wenn man z.B. die Funktion `dos/AllocDosObject', die eine Konstante und einen Zeiger auf ein Array als Argumente erwartet, nach der obigen Methode konstruiert hat, dann hat man damit auch ihre Stack-Variante! Dazu erzeugt man einfach die folgende Funktion: #include <clib/dos_protos.h> #include <pragmas/dos_pragmas.h> /* Evtl. anderer Name */ void *AllocDosObjectTags(ULONG objtype, Tag tag1, ...) { return(AllocDosObject(objtype, (struct TagItem *) &tag1); } Mit fd2pragma kann das auch automatisch geschehen. Siehe Pragmas. * Einige Funktionen bleiben aber noch übrig: Amiga.lib enthält nämlich auch Funktionen, die für sich selbst interessant sind, z.B. die BOOPSI-Funktionen (`DoMethod', `DoSuperMethod'), die Memory-Pool-Funktionen (`LibAllocPooled', `LibCreatePool', die Ersatz für entsprechende 3.0-Funktionen sind) oder `HookEntry', das sehr hilfreich bei der Programmierung von Hooks ist. Diese kann man nur durch entsprechende, disassemblierte und neu assemblierte oder compilierter Versionen ersetzen. Im AmigaFAQ-Archiv sind einige dieser Funktionen bereits enthalten. ---------- Footnotes ---------- (1) Dieses Problem betrifft vor allem Besitzer von Aztec-C, das seither nicht weiter unterstützt wird und von Dice, der manchmal etwas unvollständig ist. Ich besitze beide .. 3.12 Wie erfahre ich, was für Funktionen es gibt? ================================================= Wenn Sie sich über den Namen einer für einen bestimmten Zweck geeigneten Funktion im Unklaren sind, dann gibt es folgende Möglichkeiten: * In den Autodocs der verschiedenen Libraries findet man am Anfang eine alphabetisch sortierte Tabelle aller Funktionen, die die betreffende Library bietet. Im Hauptteil findet man dann eine detaillierte Spezifikation aller Funktionen. Siehe Include-Dateien. * Die `.FD'-Dateien bieten eine sehr kompakte Übersicht über die Funktionen der diversen Libraries, sogar mit einer kurzen Angabe der Funktionsargumente. Wenn man schon grob weiß, wonach man sucht (z.B. nur die grobe Angabe der Argumente benötigt), dann findet man hier alle gewünschten Informationen. Siehe Pragmas. Dr. Peter Kittel, peterk@cbmger.de.so.commodore.com 3.13 Der GNU C Compiler: Allgemeine Informationen und Installation ================================================================== Dieser Abschnitt enthält Informationen über den Amiga-Port des GNU C Compilers generell und die Installation insbesondere. 3.13.1 Aktuelle Version ----------------------- Die aktuelle gcc-Version ist 2.6.0 und an 2.6.1 wird gearbeitet. Sie enthält eine neue Version der ixemul.library (v40.3), aber man sollte sich wegen Fehlern, die sich auf 68000-Systemen bemerkbar machen, ixemul404.lha vom Aminet oder von meiner FTP-Site holen. Außerdem gibt es eine neue library, libnix, die das Benützen der ixemul.library verhindert. 2.6.1 wird Protos (wie bei SAS-C) enthalten, um das Kompilieren von SASC-Code unter gcc leichter zu machen. Ein neuer Assembler, gas-2.5, ist enthalten, ein Paket namens q_anote ermöglicht die Ausgabe von gemischtem C/Asm-Code zu Debugging-Zwecken. In Arbeit ist die Fähigkeit des Compilers, den Stack wachsen zu lassen, damit man vor dem Starten von gcc nicht mehr den Stack setzen muß. 3.13.2 Hardwareanforderungen ---------------------------- Jeder Amiga (vom A1000 bis zum A4000/40) ist prinzipiell in der Lage, die GNU-Utilities für AmigaDOS zu benutzen. Allerdings braucht man wenigstens 4MB RAM, um kleinere oder mittlere Projekte zu übersetzen, für größere (z.B. für gcc selbst) entsprechend mehr. Gigamem und VMM arbeiten mit gcc zusammen, es *könnte* also evtl. auch mit weniger gehen. Dazu braucht man aber eine MMU. Siehe 68EC0xx. Eine volle Installation mitsamt C++ und Objective-C, inline-Dateien und Commodore Includes (siehe Include-Dateien) benötigt ca. 20 MB Platz auf der Festplatte. Kickstart 1.2/1.3 wird nicht mehr unterstützt. Wer KS 1.2/1.3 hat, sollte sich eine bessere Kickstart-Version kaufen. Gcc arbeitet auch unter Kickstart 1.2/1.3, die volle Funktionalität ist aber erst ab Kickstart 2.x+ vorhanden. Eine schnelle CPU (z.B. 68030@25MHz oder besser) ist ebenfalls sinnvoll. 3.13.3 Wer hat es gemacht? -------------------------- Gcc und damit zusammenhängende Software wurde von den folgenden Personen auf den Amiga portiert (siehe Hilfe): Gcc v2.2.2: Markus Wild Gcc v2.3.3: Markus Wild Gcc v2.4.5: Philippe Brand, Lars Hecking, Fred Fish Gcc v2.5.0 und später: Philippe Brand, Fred Fish, Leonard Norrgard Ixemul.library: Markus Wild, Leonard Norrgard, R. Luebbert Libnix: Matthias Fleischer, Gunther Nikl Gerlib: Gerhard Müller 3.13.4 Wo finde ich die gcc-Quelltexte? --------------------------------------- Alle gcc-Quelltexte und alle Binärdateien findet man auf: 1. Aminet (wuarchive.wustl.edu und Mirror wie ftp.luth.se) in /pub/aminet/dev/gcc (siehe FTP) 2. Ramses The Amiga Flying BBS: +33-1-60037015 HST Dual v32 terbo 4800-21600 +33-1-60037713 SupraFax v32bis 4800-14400 +33-1-60037716 Tornado v22bis 1200-2400 in Topic `Development', Area `Gcc' (are 156). Den originalen GNU-Quelltext bekommt man 1. von denselben FTP-Servern wie die Binaries 2. gnu.prep.ai.mit.edu (18.71.0.38) in `/pub/gnu' 3. Ramses The Amiga Flying BBS in Topic `AmigaUnix/Unix/Linux/NetBSD', Area `Gnu Source Code' Diese Archive sollten alles Nötige enthalten, mit Ausnahme der Quelltexte der ixemul.library. Diese erhält man ebenfalls auf dem Aminet, Directory `dev/gcc'. (Zur Zeit ist die Version 40 der ixemul.library in Arbeit. Die Quelltexte werden am gleichen Ort sein.) Durch Richard Stallman, Free Software Foundation, ist festgelegt: "The GPL says that any distribution of binaries must contain either the source code or a written offer to supply source code (see the GPL for details of what is required)." Übersetzt: Die GPL (GNU General Public License) legt fest, daß jede Distribution entweder den Quelltext oder das schriftliche (oder geschriebene?) Angebot, diese zu liefern, enthalten muß. (Näheres siehe in der GPL.) 3.13.5 Inline-Dateien --------------------- Die Inline-Dateien für den gcc kann man aus den originalen FD-Dateien von Commodore wie folgt erzeugen (Siehe Include-Dateien, siehe Pragmas): CLI> Assign INCLUDE: GCC:os-include CLI> Assign FD: INCLUDE:fd CLI> Makedir INCLUDE:inline CLI> cd USR:bin/geninline CLI> gen31 Dies sollte alle Inline-Dateien in `GCC:os-include/inline' erzeugen. Falls man die 2.0- bzw. 3.0-Includes besitzt, sollte man gen20 bzw. gen30 benutzen. Inline-Dateien für OS3.1 (rev 40.13) sind in <gcc-aktuell> enthalten. Siehe Aktuelle Version. (1) Auch mit dem Programm fd2inline kann man Inline-Dateien erzeugen: CLI> fd2inline <fd_file> <proto_file> ---------- Footnotes ---------- (1) Perl Skripte haben Schwierigkeiten, die Include-Dateien von AmigaDOS korrekt zu behandeln. Hier wäre etwas freiwillige Arbeit nötig ... 3.13.6 Wie konvertiere ich die Amiga-Libraries für den gcc? ----------------------------------------------------------- Ab gcc Version 2.6.0 werden dank den libnix-Autoren (Matthias Fleischer und Gunther Nikl) AmigaDOS Linklibraries unterstützt. Wenn man trotzdem eine gcc-Linklibrary generieren will, gibt es zwei Methoden: 1. Mit hunk2gcc, dem AmigaDOS-Object-Konvertierer von Markus Wild. Dazu braucht man zunächst eine aktuelle Kopie der amiga.lib (aus dem NDU, siehe Include-Dateien). Nachdem man sich ein Directory für die konvertierten Dateien erstellt hat, wechselt man mit cd in dieses Directory und gibt das Folgende ein: hunk2gcc amiga.lib [..further libs if you like..] Dies erzeugt ein Objektfile wie a.out für jedes einzelne Modul, das die Library enthält. Diese Module muß man anschließend in einer gcc-Library zusammenfassen: ar qc libamiga.a obj.* ranlib libamiga.a Das Programm ranlib fügt eine Symboltabelle in die Library ein. (Dadurch wird der Zugriff auf die Library sehr viel schneller.) 2. Eine libamiga.a mit libnix zu generieren ist recht leicht, braucht aber einige Zeit. Man dekomprimiere sources.lha aus dem libnix-Archiv und starte ein 'make libamiga.a'. *Beachte:* Solange man keine reinen AmigaDOS-Funktionen verwendet, kann man auch eine Pseudo-Library erzeugen: cat "int dummy;" >dummy.c gcc -c dummy.c ar crv libamiga.a dummy.o mv libamiga.a gcc:lib 3.13.7 Wie installiere ich den gcc? ----------------------------------- 1. Falls dies die erste Installation von gcc ist: Mache das Folgende: cd ort_mit_sehr_viel_platz ; ÄNDERN! Gib eine Schublade an makedir gnu lha x gcc260-base.lha ; Der erste Teil, du brauchst ihn Jetzt mußt du `gnu/s/user-startup' an dein `S:User-Startup' anhängen (Ersetze Devel:GNU durch deinen eigenen Gnu Pfad). Weiter: execute gnu/s/user-startup ; setzt wichtige Assigns copy gnu/envarc/#? ENVARC: *Ändere* die folgenden Zeilen! Wenn du einen 68000- oder 68010-Amiga hast, entferne das "-020" aus allen folgenden Zeilen! lha x gcc260-c-020.lha ; Der C-compiler; du brauchst ihn lha x gcc260-doc.lha ; Wenn du die Dokumentation zu gcc willst lha x gcc260-c++-020.lha ; Wenn du C++ haben willst lha x gcc260-objc-020.lha ; Wenn du Objective-C haben willst lha x gcc260-utils.lha ; Wenn du zusätzliche Utilities haben willst ; (empfohlen zur Kompatibilität mit Unix) lha x gcc260-utilsdoc.lha ; Wenn du Dokumentation zu allen Utilities willst Mit dem Script `restorelinks' mußt du Links generieren: sh /gnu/s/restorelinks ; ÄNDERN! Füge " copy" an diese Zeile an, ; wenn du MakeLink nicht benützen willst, ; sondern Files lieber kopieren willst Schließlich: lha x gcc260-diffs.lha ; Wenn du gcc neu kompilieren willst lha x gcc260-texi.lha ; Wenn du Postscript-Doku generieren willst Auf zum nächsten Punkt und fröhliches Kompilieren! 2. Wenn du ein Upgrade deiner gcc-Umgebung von v2.5.x machen willst, dearchiviere einfach gcc260-base.lha und gcc260-c-020.lha. Gehe sicher, daß du deine frühere ixemul.library löschst, wo sie sich auch befindet. (Üblicherweise in `LIBS:') *Beachte*: Eine neue Version der ixemul.library wird verwendet, gehe bitte sicher, daß nirgends eine andere Kopie ist, die in Konflikt mit der neuen Version geraten kann. 3.13.8 Kompilieren ------------------ Wie wär's mit einem netten `Hello world'? #include <stdio.h> main() { printf("Hello World!\n"); } Das war recht einfach ;-) Jetzt müssen wir es kompilieren. Es gibt eine Menge Optionen in gcc, aber die einfachste Möglichkeit zu kompilieren ist: CLI> gcc -o hello hello.c Einfach? Hier sind mehr Optionen: Ziel-Prozessoren von Motorola: Man kann reinen 68000 code, 68020, 68030, 68040 und/oder 68881 kompilieren. (Siehe Gcc-Dokumentation, Kapitel `Invoking Gcc/SubModel Options/M680X0 Options for Motorola specific compilation flags'. CLI> gcc -m68020 -m68881 -o hello hello.c Dies kompiliert Programme mit 68020 Code und direkten FPU-Befehlen und bindet mit den beschleunigten Libraries aus `GCC:lib/lib020'. Optimierung: Entweder du willst keine Optimierung oder du gibst `-O' an, das den Code optimiert, oder `-O2' für bessere Optimierung (Siehe die Dokumentation im Kapitel `Invoking Gcc/Optimize Options'). Inzwischen gibt es auch eine `-O3' Option, die noch weiter geht. CLI> gcc -O2 -o hello hello.c Ein schnelles "Hello World" ;-) Codegenerierung: Vielleicht willst du residente Programme haben. Die Option dazu heißt `-resident'. CLI> gcc -resident -o hello hello.c Natürlich kannst du alle Optionen mischen, so etwa: CLI> gcc -O2 -m68020 -m68881 -resident -o hello hello.c Dies wird ein hoch optimiertes residentes Programm für 68020 und 68881 ergeben. *Wichtig:* Wenn du nur AmigaOS-Funktionen verwendest oder aus irgendwelchen philosophischen Gründen keine ixemul.library verwenden willst, dann kannst du diese loswerden durch: CLI> gcc -noixemul -o foobar foobar.c natürlich nur, wenn du libnix hast (enthalten in gcc 2.6.0). 3.13.9 Wichtige Informationsquellen ----------------------------------- Der aktuelle Betreuer des Amiga-Ports von gcc ist: Philippe BRAND Fidonet: Ramses The Amiga Flying BBS 2:320/104.21 Email: phb@colombo.telesys-innov.fr (ONLY for personnal email). Ftp: colombo.telesys-innov.fr:/pub/amigados-gnu or /pub/incoming/uploads for uploads. Es gibt auch eine Mail-Liste in Finnland. Siehe Mail-Listen. Philippe Brand wird im Normalfall Fragen an diese Liste weiterleiten.